Data services framework workflow processing

ABSTRACT

A data services framework workflow processing system and method is disclosed. The method includes receiving a request for data from a client and based on the request, determining a workflow to process the request. The method also includes based on the workflow, generating a plurality of backend calls. Additionally, the method includes based on the plurality of backend calls, selecting one or more data sources from a plurality of data sources. The method also includes transmitting one or more of the plurality of backend calls to the selected data sources and receiving, from each the selected data sources, a response to the plurality of backend calls.

TECHNICAL FIELD OF THE INVENTION

The invention relates generally to data processing techniques, and morespecifically to data services framework workflow processing.

BACKGROUND OF THE INVENTION

Systems and code underlying enterprise applications may be varied andunique. Data processing, storage, and retrieval may be unique for eachapplication, each application may use its own business logic todetermine backend call sequences. The application may apply specificvalidation rules to data retrieved from a data source.

SUMMARY OF THE INVENTION

In accordance with a particular embodiment of the present disclosure,method includes receiving a request for data from a client and based onthe request, determining a workflow to process the request. The methodalso includes based on the workflow, generating a plurality of backendcalls and based on the plurality of backend calls, selecting one or moredata sources from a plurality of data sources. Additionally, the methodincludes transmitting one or more of the plurality of backend calls tothe selected data sources and receiving, from each the selected datasources, a response to the plurality of backend calls.

In accordance with another embodiment of the present disclosure, asystem includes a data services module operable to receive a request fordata from a client and based on the request, determine a workflow toprocess the request. The data services modules is also operable to basedon the workflow, generate a plurality of backend calls and based on theplurality of backend calls, select one or more data sources from aplurality of data sources. The data service module is further operableto transmit one or more of the plurality of backend calls to theselected data sources and receive, from each of the selected datasources, a response to the plurality of backend calls. Additionally, thesystem includes the one or more data sources operable to receive, fromthe data services module the one or more of the plurality of backendcalls and transmit, to the data services module, the response.

In accordance with yet another embodiment of the present disclosure, acomputer readable non-transitory medium is encoded with logic, and thelogic is operable, when executed on a processor to receive a request fordata from a client and based on the request, determine a workflow toprocess the request. The logic is also operable to based on theworkflow, generate a plurality of backend calls and based on theplurality of backend calls, select one or more data sources from aplurality of data sources. The logic is further operable to transmit oneor more of the plurality of backend calls to the selected data sourcesand receive, from each the selected data sources, a response to theplurality of backend calls.

Technical advantages of particular embodiments of the present disclosureinclude performing appropriate protocol and/or format translation,transmitting requests to appropriate data sources, and combiningmultiple responses into a combined response. By so doing, particularembodiments, facilitate communication between clients and data sources.Particular embodiments may provide a common framework for applicationand data access, thereby standardizing data access components. Moreover,embodiments of the present disclosure may access federated databasesusing multi-step processes. Some embodiments also facilitate theconstruction of workflows through a visual programming model. As aconsequence, parallel backend calls are simple to construct. In someembodiments, the compensation mechanism requires not customized and/orspecialized programming. Thus, particular embodiments are able to accessvarious backend providers and/or data sources, and provide an extensibleand scalable framework that allows custom schema adapters, customerservice providers and other similar customization. Particularembodiments allow for tracking support, and may use the toolset ofMicrosoft's .NET 3.0 workflow engine to create workflows. Additionally,particular embodiments, provide a built-in visibility check, and mayenforce visibility checks at multiple levels: at the orchestrationlevel, at each backend call, and at attribute levels. Moreover,particular embodiments may administer visibility policies from a singlelocation for different backend data sources.

Other technical advantages of the present disclosure will be readilyapparent to one skilled in the art from the following figures,description, and claims. Moreover, while specific advantages have beenenumerated above, various embodiments may include all, some, or none ofthe enumerated advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following description taken inconjunction with the accompanying drawings, in which:

FIG. 1 illustrates a system in accordance with particular embodiments ofthe present disclosure, including clients, a data request handler, adata services module, an orchestration component, an adapter, datasources, and a network;

FIG. 2 illustrates a particular workflow in more detail, accordingly toparticular embodiments of the present disclosure;

FIG. 3 is a flow chart illustrating a particular operation of the systemof FIG. 1 in accordance with particular embodiments of the presentdisclosure;

FIG. 4 is an example Graphical User Interface for retrieving and editinginformation associated with workflows, according to particularembodiments of the present disclosure; and

FIG. 5 represents an example visibility policy in accordance with aparticular embodiment of the present disclosure.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a system 10 in accordance with certain embodiments ofthe present disclosure. System 10 comprises clients 20 that communicatewith data request handler 40. Data services module 50 and orchestrationcomponent 60 facilitate the retrieval of information from data sources90.

In general, system 10 is operable to process a request for data fromclients 20 by orchestrating a sequence of backend calls in accordancewith a workflow in order to retrieve data from one or more differentdata sources 90. To facilitate processing of the request, data requesthandler 40 transforms the request into a standard format. Data requesthandler 40 may transmit the request in a standard format to dataservices module 50. Orchestration component 60 may then select anappropriate workflow to facilitate further processing of the request.According to the workflow, orchestration component 60 communicates withdata sources 90 to retrieve information in response to the request. Datasource 90 transmits a response to orchestration component 60.Orchestration component 60 receives a plurality of responses associatedwith the plurality of operations in the workflow, and combines theplurality of responses into a combined response. Orchestration component60 transmits the combined response to data request handler 40, which maytranslate the combined response into a format readable by the requestingclient 20.

Clients 20 (each of which may be referred to individually as “client 20”or collectively as “clients 20”) transmit request 12 to web module 30.Request 12 represents any form of data transmission, includinginformation transmitted in an Internet Protocol packet, Ethernet frame,Asynchronous Transfer Mode cell, Frame Relay frame, and/or any othersuitable mode of data communication. Request 12 may include a request toretrieve data, a request to store data, a request to change data, arequest to delete data, and/or a request to process data in any suitablemanner. Clients 20 may transmit request 12 in a particular format. Forexample, request 12 may be formatted in XML, HTML, X4mL, OASIS XACML, orany other suitable format.

In particular embodiments, clients 20 represent general orspecial-purpose computers operating software applications capable ofperforming the above-described operations. For example, clients 20 mayinclude, but are not limited to, laptop computers, desktop computers,portable data assistants (PDAs), and/or portable media players. In someembodiments, client 20 comprises a general-purpose personal computer(PC), a Macintosh, a workstation, a Unix-based computer, a servercomputer, or any suitable processing device. Additionally, in particularembodiments, client 20 may include one or more processors operable toexecute computer logic and/or software encoded on non-transitorytangible media that performs the described functionality. Client 20 mayalso include one or more computer input devices, such as a keyboard,trackball, or a mouse, and/or one or more Graphical User Interfaces(GUIs), through which a user may interact with the logic executing onthe processor of client 20. In general, client 20 includes anyappropriate combination of hardware, software, and/or encoded logicsuitable to perform the described functionality. Additionally, clients20 may be connected to or communicate with web module 30, data requesthandler 40, and/or data services module 50, directly or indirectly overnetwork 100. Clients 20 may couple to network 100 through a dedicatedwired or wireless connection, or may connect to network 100 only asneeded to receive, transmit, or otherwise execute applications. AlthoughFIG. 1 illustrates, for purposes of example, a particular number andtype of clients 20, alternative embodiments of system 10 may include anyappropriate number and type of clients 20, depending on the particularconfiguration of system 10.

Web module 30 represents a computer that transmits request 12 to datarequest handler 40. Prior to transmitting request 12, web module 30 mayreceive request 12 from clients 20 and/or generate request 12 inresponse to information received from client 20. For purposes ofexample, FIG. 1 illustrates web module 30 receiving request 12 fromclient 20 and transmitting request 12 to data request handler 40.

Data request handler 40 represents a computer that receives request 12from client 20 and/or web module 30. Request 12 may be formatted in aparticular format associated with the particular client 20 thattransmitted request 12. Thus, because request 12 may be formatted in avariety of different formats, data request handler 40 may translaterequest 12 into a format readable by other components of system 10,referred to herein as request 12′. Data request handler 40 also receivesresponse 16′ from other components of system 10, and translates response16′ into a format readable by the particular requesting client 20,referred to herein as response 16″.

Data services module 50 orchestrates the retrieval, storage, deletion,and/or other processing of data responsive to request 12′ from one ormore data sources 90 and while ensuring that the requesting client 20performs only permitted actions and views only permitted data. Dataresponsive to request 12′ may be located on different data sources 90.Thus, data service module 50 may determine how and from which datasources 90 data is retrieved. In order to orchestrate the retrieval ofdata, data service module 50 selects an appropriate workflow 62, selectsand/or generates backend calls 14 based on the selected workflow 62, andtransmits backend calls 14 to adapter 80. In general, workflow 62governs how requests 12 are processed. In some embodiments, workflow 62defines a particular sequence in which backend calls 14 are transmittedto adapter 80. A particular workflow 62 may be associated with aparticular application that generates request 12, a particular user thatgenerates request 12, particular information requested by request 12,and/or a particular format associated with request 12. Thus, dependingon the format, source, user, information, and/or other relevantcharacteristic associated with request 12′, data services module 50selects a particular workflow 62 from memory 54 to determine how toprocess request 12′.

Workflow 62 includes one or more backend calls 14. Backend calls 14represent predetermined procedures for processing data responsive torequest 12.′ In some embodiments, backend call 14 defines a particularoperation, procedure, and/or process for responding to a particularrequest 12′. Backend call 14 may indicate a particular data source 90that includes information responsive to request 12′ and a particularmanner of interacting with data source 90. Backend call 14 may indicatea particular protocol to use for communication with data source 90.Backend call 14 may specify a particular format readable by one or moredata sources 90. For example, backend call 14 may define a procedure toretrieve a username from a customer relations relational databasemanagement system. Another backend call 14 may define a procedure toretrieve a customer's financial portfolio from a mainframe. Inparticular embodiments, some backend calls 14 are dependent on theresults of other backend calls 14. For example, a first backend call 14may define a procedure to retrieve a customer's profile from a customerrelations relational database management system. The profile mayindicate the types of accounts associated with the customer. Based onthe results of the first backend call 14, a second backend call 14 maydefine a procedure to retrieve information associated with the accountsassociated with the customer.

Data service module 50 may include sub-components that facilitate theprocessing of data responsive to request 16′ and ensure that arequesting client 20 only performs permitted actions and/or viewspermitted data. In particular embodiments, data services module 50comprises sub-components, such as orchestration component 60 andvisibility component 70. Orchestration component 60 receives request12′, selects an appropriate workflow 62, transmits backend calls 14 toadapter 80, receives response 16′, combines responses 16′ into acombined response 16′, and transmits the combined response 16′ to datarequest handler 40 as discussed above.

Visibility component 70 regulates the types of actions that client 20 ispermitted to perform within system 10, and may determine which aspectsof response 16′ a particular client 20 is permitted to view. Visibilitycomponent 70 includes memory 75, which stores one or more visibilitypolicies 76. Visibility policy 76 includes rules that define the typesof actions that client 20 is permitted to perform within system 10 andwhich aspects of response 16 client 20 is permitted to view. Forexample, visibility policy 76 may include a rule that indicates afinancial advisor is permitted to retrieve data, but not permitted towrite data. Thus, if a financial advisor transmits a request 12 thatindicates a request to write data, visibility component 70 may prevent abackend call 14 that writes data from being transmitted to adapter 80.

Adapter 80 represents a computer that performs translation operations onbackend calls 14 that facilitate communication between data servicesmodule 50 and data sources 90. For example, adapter 80 receives backendcalls 14 from data service module 50 in a particular format. Asdiscussed above, adapter 80 may receive backend call 14 in a standardformat, and translate backend call 14 into a second format readable by aparticular data source 90, referred to herein as backend call 14′.Similarly, adapter 80 receives a response 16 from data source 90, andtranslates response 16 into a standard format readable by othercomponents of system 10, referred to herein as response 16′. Oncereceived from data source 90 and translated into a standard format,adapter 80 transmits response 16′ to data services module 50.

In some embodiments, web service module 30, data request handler 40,data service module 50, and adapter 80 represent a general-purpose PC, aMacintosh, a workstation, a Unix-based computer, a server computer,and/or any suitable processing device. Accordingly, web services module30, data request handler 40, data services module 50, and adapter 80 mayinclude one or more processors and/or memory to perform the abovedescribed functions. For example, as shown in FIG. 1, web servicesmodule 30 includes processor 32 and memory 34, data request handler 40includes processor 42 and memory 44, data services module 50 includesprocessor 52 and memory 54, and adapter 80 includes processor 82 andmemory 84.

Memory 34, 44, 54, and 84 each comprise any suitable arrangement of RAM,ROM, magnetic computer disk, CD-ROM, or other magnetic or opticalstorage media, or any other volatile or non-volatile memory devices thatstore one or more files, lists, tables, or other arrangements ofinformation. Although FIG. 1 illustrates memory 34, 44, 54, and/or 84 asbeing internal to a respective component of system 10, it should beunderstood that memory 34, 44, 54, and/or 84 may be internal or externalto the respective component, depending on particular implementations.Memory 34, 44, 54, and/or 84 may be separate from or integral to othermemory devices to achieve any suitable arrangement of memory devices foruse in system 10.

Memory 34, 44, 54, and/or 84 stores one or more of request 12, request12′, backend call 14, response 16, response 16′, workflow 62, and/orvisibility policy 76. As shown in FIG. 1, memory 34 stores logic 36,memory 44 stores logic 46, memory 54 stores logic 56, and memory 84stores logic 86. Logic 36, 46, 56, and/or 86 generally comprise rules,algorithms, code, tables, and/or other suitable instructions forperforming the operations as described herein.

Memory 34, 44, 54, and 84 are communicatively coupled to processor 32,42, 52, and 82, respectively. Processor 32, 42, 52, and 82 are generallyoperable to execute logic 36, 46, 56, and 86, respectively to performthe operations as described herein. Processor 32, 42, 52, and 82 eachcomprise any suitable combination of hardware and/or softwareimplemented in one or more modules to provide the described function oroperation.

Data sources 90 represent data storage devices that store dataresponsive to request 12′. Data sources 90 a, 90 b, 90 c, and 90 d (eachof which may be referred to individually as “data source 90” orcollectively as “data sources 90”) represent any device capable ofstoring, retrieving and/or processing any suitable form of electronicdata. In particular embodiments, data source 90 represents a mainframe,a server, an electronic disk drive, a relational database managementsystem, a personal computer, network attached storage, a storage areanetwork, and/or any other electronic storage device to store data. Inparticular embodiments, a particular data source 90 may be differentwith respect to other data sources 90. For example, data source 90 a mayrepresent a disk drive in a personal computer storing a flat file, datasource 90 b may represent a relational database management system thatstores tables of customer account information, and data source 90 c mayrepresent a storage area network that stores transaction history. Datasource 90 transmits data in response to backend call 14 as response 16.Response 16 represents any form of data transmission, includinginformation transmitted in an Internet Protocol packet, Ethernet frame,Asynchronous Transfer Mode cell, Frame Relay frame, and/or any othersuitable mode of data communication. Response 16 may include data thatclient 20 requested, an acknowledgement that particular data was writtenand/or deleted, an error message, and/or any other data responsive tobackend call 14′ and/or backend call 14. Data source 90 may transmitresponse 16 in a particular format.

In order to facilitate communication among the various components ofsystem 10, clients 20, web module 30, data request handler 40, dataservices module 50, adapter 80, and data sources 90 are communicativelycoupled via one or more networks 100. Network 100 may represent anynumber and combination of wireline and/or wireless networks suitable fordata transmission. Network 100 may, for example, communicate internetprotocol packets, frame relay frames, asynchronous transfer mode cells,and/or other suitable information between network addresses. Network 100may include one or more intranets, local area networks, metropolitanarea networks, wide area networks, cellular networks, all or a portionof the Internet, and/or any other communication system or systems at oneor more locations. Although FIG. 1 illustrates for purposes of example asingle network 100, particular embodiments of system 10 may include anyappropriate number and type of networks 100 that facilitatecommunication among one or more various components of system 10.

In an exemplary embodiment of operation, client 20 transmits request 12to web module 30. Request 12 may include a request to retrieve data, arequest to store data, a request to modify data, a request to deletedata, and/or a request to process data in any suitable manner. Asdiscussed above, clients 20 may transmit request 12 in a particularformat. For example, request 12 may be formatted in XML, HTML, X4mL,OASIS XACML, or any other suitable format. In some embodiments, client20 transmits request 12 to web module 30, which simply relays and/orretransmits request 12 to data request handler 40. In other embodiments,web module 30 generates request 12 based on input received from client20. In such embodiments, web module 30 generates and transmits request12 to data request handler 40 based on the input received. For example,web module 30 may represent an interactive web page, web-based inputform, web service and/or any other suitable interactive applicationoperating over network 100. Client 20 may input information into aninteractive application, and based on the received input, web module 30may generate request 12 and transmit request 12 to data request handler40. For discussion purposes, it is assumed that client 20 transmitsrequest 12 that requests a customer profile based on a customeridentification number.

Whether generated by client 20 or web module 30, data request handler 40receives request 12. Request 12 may be in a first format associated witha particular client 20. In order to facilitate processing by othercomponents of system 10, data request handler 40 translates request 12from a first format into a second format readable by other components ofsystem 10. In particular embodiments, data request handler 40 translatesrequest 12 into a canonical and/or standardized format, represented inFIG. 1 as request 12′. Once translated, data request handler 40transmits request 12′ to data services module 50. In particularembodiments, data request handler 40 transmits request 12′ toorchestration component 60 within data services module 50. As discussedabove, request 12′ includes a particular requested operation andassociated parameters. In the illustrated example, request 12′ includesa request to retrieve a customer profile, with the customeridentification number representing an associated parameter.

Once data services module 50 receives request 12′, orchestrationcomponent 60 selects an appropriate workflow 62 to process request 12′.Orchestration component may select an appropriate workflow 62 based on aparticular operation requested by request 12′. In this example,orchestration component selects a “customer profile” workflow 62 thatincludes backend calls 14 for retrieving particular data associated witha customer profile. In some embodiments, a particular workflow 62 may beassociated with a particular application that generates request 12,and/or a particular format associated with request 12. Thus, dependingon request 12′, orchestration component 60 may select a particularworkflow 62 to determine an appropriate manner in which to processrequest 12′.

Workflow 62 defines a manner to process request 12′ by specifying asequence of one or more backend calls 14. Backend calls 14 representpredetermined procedures that when performed in sequence, suitablyrespond to request 12′. In some embodiments, backend call 14 defines aparticular operation, procedure, and/or process for responding to aparticular request 12. Backend call 14 may indicate a particular datasource 90 responsive to request 12′ and/or a particular manlier ofinteracting with data source 90.

Backend calls 14 specified in workflow 62 may be processed in paralleland/or in serial. For example, for parallel backend calls 14,orchestration component 60 may perform operations specified by eachparallel backend call 14 substantially simultaneously. As a result,orchestration component 60 does not wait for a response from aparticular data source 90 before performing operations for other backendcalls 14. In some embodiments, backend calls 14 specified in workflow 62are processed in serial. For example, backend calls 14 may be processedsuch that orchestration component 60 transmits a first backend call 14,waits for a response from a particular data source 90, and thentransmits a second backend call 14. The results of one backend call 14may be used as input to another backend call 14. In some embodiments,backend calls 14 may be transmitted conditionally. For example, aparticular backend call 14 may be transmitted on the condition thatparticular data exists and/or matches certain criteria.

Prior to transmitting backend calls 14, orchestration component 60 mayconsult visibility component 70 to determine whether a requesting client20 is permitted to perform the particular operations specified inworkflow 62. In order to make an appropriate determination, visibilitycomponent 70 retrieves an appropriate visibility policy 76 from memory75. Visibility policy 76 may be associated with a particular client 20,a particular application, a particular operation, a particular workflow62, and/or any other relevant aspect of system 10. In particularembodiments, visibility component 70 determines call level policies andattribute level policies. For example, a call level policy mightindicate that a particular client 20 may be permitted to retrieve datafrom data sources 90, but not write data to data sources 90. In someembodiments, a particular client 20 may not be permitted to retrieveinformation from particular data sources 90. As another example, anattribute level policy may indicate that client 20 may not be permittedto view certain portions of data retrieved from data source 90. Forexample, client 20 may retrieve a user profile from data source 90 thatincludes a home address, telephone number, occupation, and socialsecurity number. Visibility component 70 may restrict client 20 fromviewing the social security number, for instance, while permittingclient 20 to view the home address, telephone number, and occupation.

Once an appropriate workflow 62 is selected, orchestration component 60transmits permitted backend calls 14 to adapter 80. In this particularexample, request 12′ requests a customer profile that includes as aparameter a customer identification number. Thus, the selected workflow62 includes a sequence of backend calls 14 that determine how toretrieve a customer profile from data sources 90 based on a customeridentification number. For example, the selected workflow 62 may includea serial backend call 14 a to retrieve a customer name from a particulardata source 90 based on the customer identification number. Accordingly,orchestration component 60 transmits backend call 14 a to adapter 80.Adapter 80 transmits backend call 14 a to an appropriate data source 90,shown in FIG. 1 as data source 90 a. Data source 90 a transmits response16 a, which includes the customer name. Once the customer name isreceived in response 16 a, parallel backend calls 14 b, 14 c, and 14 dare transmitted that request the customer work address, customer accountnumber, and customer account history, respectively from relevant datasources 90 based on the customer name received in response 16 a. Oncethe responsive data is received in responses 16 b, 16 c, and 16 d fromdata sources 90, another serial backend call 14 e is transmitted to loga record of the data retrieval in data source 90 d. Data source 90 dtransmits an acknowledgement of the logged record in response 16 e.

One aspect of system 10 may enable repetitive retrievals for similarinformation. For example, in particular embodiments, orchestrationcomponent 60 may perform looping or branching operations with respect toparticular backend calls 14. For example, once a particular response 16is received, orchestration component 60 may transmit another backendcall 14 based on response 16. Thus, orchestration component 60 transmitsa particular backend call 14 more than once. For example, in thisexample, backend call 14 b may retrieve an account number of a customer,based on the customer name. If there are more than one account numbers,which may be indicated in response 16 b, orchestration component 60 maytransmit backend call 141, which performs the same operation as backendcall 14 b and retrieves another customer account number from data source90. The particular operation associated with backend call 14 may berepeated until all data responsive to the backend call 14 is processed.As a result, orchestration component 60 may perform looping and/orbranching operations.

Because data sources 90 may represent different types of storage devicesstoring and/or communicating in different data formats and/or protocols,adapter 80 may perform translating functions with respect to backendcalls 14. In some cases, adapter 80 may translate a format of backendcall 14 to a format readable by a particular data source 90. As shown inFIG. 1, adapter 80 translates backend calls 14 a, 14 b, 14 c, 14 d, 14e, and 14 f into backend calls 14 a′, 14 b′, 14 c′, 14 d′, 14 e′ and 14f′, respectively. The translation of backend call 14 may includetranslating backend call 14 into a protocol in which adapter 80interacts with a particular data source 90, translating backend call 14into a format in which data in data source 90 is formatted, and/ortranslating any relevant data to facilitate communication with one ormore data sources 90. Conversely, adapter 80 translates responses 16from a format readable by the relevant data source 90 to a formatreadable by other components of system 10. In this particular example,adapter 80 translates responses 16 a, 16 b, 16 c, 16 d, 16 e, and 16 finto a format readable by data service module 50 and/or other componentsof system 10, shown in FIG. 1 as 16 a′, 16 b′, 16 c′, 16 d′, 16 e′, and16 f′, respectively. Once received from data source 90 and translatedinto a standard format, adapter 80 transmits responses 16 a′, 16 b′, 16c′, 16 d′, 16 e′, and 16 f′ in a standard format to orchestrationcomponent 60.

It should be noted that errors may occur during the processing ofworkflow 62. Because errors may occur, data service module 50 provides amanner of restoring data to a state prior to the to the initiation ofworkflow 62. This compensation may correct for errors that occur duringthe processing of workflow 62. In some embodiments, orchestrationcomponent 60 performs compensation with respect to particular backendcalls 14. As an example, a particular backend call 14 may attempt towrite data to a particular data source 90. Prior to writing data to aparticular data source 90, orchestration component 60 stores statusinformation 64. Status information 64 stores data indicating the currentstate of the particular data source 90. If an error results from otherparallel backend calls 14 and/or subsequent backend calls 14,orchestration component 60 uses information stored in status information64 to write, delete, and/or update data to rollback data source 90 toits state prior to the first backend call 14 operation. As a result,orchestration component 60 prevents corruption of data source 90 fromerrors in backend call 14 operations.

After receiving responses 16 a, 16 b, 16 c, 16 d, 16 e, and 16 f,orchestration component 60 combines the multiple received responses 16into a combined response 16′. Response 16′ may thus include all the dataretrieved in accordance with workflow 62. Either prior to or subsequentto combining responses 16 into response 16′, visibility component 70 mayfilter response 16′. As discussed above, filtering response 16′ includesrestricting client 20 from viewing certain data included in the combinedresponse 16′. Visibility component 70 may delete, remove, and/or filterparticular data according to policies defined in visibility policy 76.In the illustrated example, a particular client 20 may be prohibited byvisibility policy 76 from viewing a customer's home address.Accordingly, visibility component 70 may restrict client 20 from viewingthe customer's home address while permitting client 20 to view thecustomer's name, account number, and account history.

To suitably filter response 16′, visibility component 70 may consultvisibility policy 76. Visibility policy 76 may be based on OASIS XACMLstandards. Visibility policy 76 may define controls based on one or morefactors, including, but not limited to the environment (such as, forexample, a general classification of an application generating request12), the source (such as, for example, the role of the user generatingrequest 12), the resource (such as, for example, the particular type ofdata requested by request 12), and the action (such as, for example,get, find, write, read, and/or store). Visibility policy 76 may beconfigured according to input received from a user interface andcommunicated to data services module 50.

After filtering response 16′, orchestration component 60 transmitsresponse 16′ to data request handler 40. As discussed above, datarequest handler 40 may translate response 16′ into a response 16″ thathas a format readable by a particular client 20 and/or web module 30.Data request handler 40 subsequently transmits response 16″ to webmodule 30 and/or client 20. In particular embodiments, client 20displays information indicated in response 16″ to a user operatingclient 20.

By performing orchestration of backend calls 14 specified in anappropriate workflow 62, system 10 enables clients 20 to transparentlyretrieve, store, delete, modify, and/or otherwise process data frommultiple different data sources 90. Additionally, by performingappropriate protocol and/or format translation, transmitting backendcalls 14 to appropriate data sources 90, and combining multipleresponses 16 into a combined response 16′, data services module 50facilitates communication between clients 20 and data sources 90. As aresult, system 10 may provide numerous operational benefits. System 10may provide a common framework for application and data access, therebystandardizing data access components. Moreover, system 10 may accessfederated databases using multi-step processes. System 10 alsofacilitates the construction of workflows 62 through a visualprogramming model. As a consequence, parallel backend calls 14 aresimple to construct. In some embodiments, the compensation mechanismrequires not customized and/or specialized programming. System 10 isable to access various backend providers and/or data sources 90, andprovides an extensible and scalable framework that allows custom schemaadapters, customer service providers and other similar customization.Particular embodiments allow for tracking support, and may use thetoolset of Microsoft's .NET 3.0 workflow engine to create workflows 62.System 10 provides a built-in visibility check, and may enforcevisibility checks at multiple levels: at the orchestration level, ateach backend call 14, and at attribute levels. Moreover, system 10 mayadminister visibility policies 76 from a single location for differentbackend data sources 90.

As a result, system 10 provides numerous operational benefits.Nonetheless, particular embodiments may provide some, none, or all ofthese operational benefits, and may provide additional operationalbenefits.

Modifications, additions, or omissions may be made to system 10 withoutdeparting from the scope of the invention. For example, in theillustrated embodiment, client 20, web module 30, data request handler40, data services module 50, adapter 80, and data sources 90 arerepresented as different components of system 10. However, the functionsof client 20, web module 30, data request handler 40, data servicesmodule 50, adapter 80, and data sources 90 may be performed by anysuitable combination of one or more servers or other components at oneor more locations. In the embodiment where the various components areservers, the servers may be public or private servers, and each servermay be a virtual or physical server. The server may include one or moreservers at the same or at remote locations. Also, client 20, web module30, data request handler 40, data services module 50, adapter 80, anddata sources 90 may include any suitable component that functions as aserver. Additionally, system 10 may include any number of clients 20,web modules 30, data request handlers 40, data services module 50,adapters 80, and data sources 90. Any suitable logic may perform thefunctions of system 10 and the components within system 10.

FIG. 2 illustrates an example operation of system 10 according to aparticular embodiment. FIG. 2 includes a workflow 62, backend calls 14a-f, and response 16.

As shown in FIG. 2, workflow 62 includes backend calls 14 a, 14 b, 14 c,14 e, and 14 f. In particular embodiments, workflow 62 specifies aparticular order in which backend calls 14 a-f are transmitted toadapter 80 (not shown in FIG. 2). For example, workflow 62 includesserial backend calls 14 a and 14 f, and parallel backend calls 14 b-e.Backend call 14 a is transmitted first, and orchestration component 60waits for response 16 from a relevant data source 90 before transmittingbackend calls 14 b-e. As a result, response 16 received in response totransmitting backend call 14 a may be used as input for one or more ofparallel calls 14 b-e.

Once orchestration component 60 receives response 16 in response tobackend call 14 a, orchestration component 60 transmits backend calls 14b-e in parallel. For example, orchestration component 60 may performoperations specified by backend calls 14 b-e substantiallysimultaneously. As a result, orchestration component 60 does not waitfor a response from data source 90 for backend call 14 b, for example,before performing operations for the remaining parallel backend calls 14c-e. Orchestration component 60 receives a response 16 in response toeach of parallel backend calls 14 b-e. Once orchestration component 60receives response 16 for each of backend calls 14 b-e, orchestrationcomponent 60 may transmit serial backend call 14 f. Backend call 14 fmay use information provided by one or more responses 16 received inresponse to parallel backend calls 14 b-e and/or serial backend call 14a. Subsequently, orchestration component 60 receives a response 16 inresponse to backend call 14 f.

Once responses 16 are received for each of backend calls 14 a-f,orchestration component 60 may combine responses 16 into a combinedresponse 16. As discussed above with respect to FIG. 1, orchestrationcomponent 60 may translate response 16 into a format readable by client20. Orchestration component 60 may then transmit the combined response16 to an appropriate data request handler 40 and/or other appropriatecomponent of system 10.

Although FIG. 2 illustrates an example orchestration component 60transmitting six backend calls 14 in a particular sequence, it should beunderstood that particular embodiments of system 10 may includetransmitting any number and combination of backend calls 14 in anysequence.

FIG. 3 is a flow diagram illustrating an operation of system 10 inaccordance with a particular embodiment. It should be understood thatthe flow diagram illustrated in FIG. 3 represents one example of anoperation that may be performed in a particular embodiment of system 10.System 10 may perform other operations in accordance with particularembodiments as described in the present disclosure.

Operation, in the illustrated example, begins at step 300 with datarequest handler 40 receiving a request 12. In particular embodiments,data services module 50 may receive request 12 from data request handler40. For example, client 20 may transmit request 12 to web modules 30. Insome embodiments, web module 30 generates request 12 based on inputreceived from client 20. Web module 30 transmits request 12 to datarequest handler 40. Data request handler 40, in some embodiments,translates request 12 from a first format into a second format readableby other components of system 10. In particular embodiments, datarequest handler 40 translates request 12 into a canonical and/orstandardized format readable by other components of system 10. Oncetranslated, data request handler 40 transmits request 12 to dataservices module 50. In particular embodiments, data request handler 40transmits request 12 to orchestration component 60 within data servicesmodule 50.

At step 302, orchestration component 60 selects an appropriate workflow62 to process request 12. Orchestration component 62 may select anappropriate workflow 62 stored in memory 54. A particular workflow 62may be associated with a particular application that generates request12, particular format associated with request 12, a particular operationrequested by request 12, and/or any other appropriate aspect of system10. For example, orchestration component 62 may select a “write customerinformation” workflow 62 to process a request 12 that requests to writea customer address to a customer profile. Thus, depending on request 12,orchestration component 60 may select a particular workflow 62 todetermine an appropriate manner in which to process request 12. Workflow62 includes one or more backend calls 14 that determine howorchestration component 60 processes request 12.

At step 304, orchestration component 60 receives and/or generates aplurality of backend calls 14 as indicated in the selected workflow 62.In particular embodiments, backend calls 14 represent predeterminedprocedures for responding to request 12. In some embodiments, backendcall 14 defines a particular operation, procedure, and/or process forresponding to a particular request 12. Backend call 14 may indicate aparticular data source 90 responsive to request 12 and a particularmanner of interacting with data source 90. Workflow 62 also indicates aparticular sequence in which backend calls 14 are processed.

At step 306, orchestration component 60 determines whether the nextbackend call 14 in the sequence of backend calls 14 is a serial orparallel backend call 14. In particular embodiments, backend calls 14may be processed serially and/or in parallel. Additionally, response 16to a first backend call 14 may be used as input to a subsequent backendcall 14. If orchestration component 60 determines the next backend call14 is a serial backend call, operation proceeds to step 308. Iforchestration component 60 determines the next backend call 14 is aparallel backend call, operation proceeds to step 314.

At step 308, orchestration component 60 selects one or more data sources90 from a plurality of data sources 90 based on the serial backend calls14. In particular embodiments, backend call 14 indicates a particulardata source 90 that includes data requested by request 12 a particularprotocol for interacting with data source 90. In some embodiments,backend call 14 specifies a particular format readable by one or moredata sources 90.

At step 310, orchestration component 60 transmits the one or moregenerated backend calls 14 to the selected one or more data sources 90.Orchestration component 60 may transmit the one or more generatedbackend calls 14 to the selected one or more data sources 90 bytransmitting the one or more backend calls 14 to adapter 80. Adapter 80may perform appropriate translating and/or formatting operations asdiscussed above. Adapter 80 may subsequently transmit formatted and/ortranslated backend calls 14 to the selected one or more data sources 90.

At step 312, orchestration component 60 receives one or more responses16 from data sources 90. Based on information indicated in backend call14, data source 90 performs a particular operation, and transmits theresults to orchestration component 60 by transmitting response 16. Inparticular embodiments, data source 90 transmits response 16 to adapter80, which may perform translating and/or formatting operations asdiscussed above. Adapter 80 may then transmit response 16 toorchestration component 60. Operation proceeds by returning to step 306.

At step 314, orchestration component 60 selects one or more data sources90 from a plurality of data sources 90 based on the backend calls 14processed in parallel. In particular embodiments, backend call 14indicates a particular data source 90 that includes data requested byrequest 12 a particular protocol for interacting with data source 90. Insome embodiments, backend call 14 specifies a particular format readableby one or more data sources 90.

At step 316, orchestration component 60 transmits the parallel backendcalls 14 to the selected one or more data sources 90. Orchestrationcomponent 60 may transmit the one or more generated backend calls 14 tothe selected one or more data sources 90 by transmitting the one or morebackend calls 14 to adapter 80 substantially simultaneously. Adapter 80may perform appropriate translating and/or formatting operations asdiscussed above. Adapter 80 may subsequently transmit formatted and/ortranslated backend calls 14 to the selected one or more data sources 90.

At step 318, orchestration component 60 receives one or more responses16 from data sources 90. Based on information indicated in backend call14, data source 90 performs a particular operation, and transmits theresults to orchestration component 60 by transmitting response 16. Inparticular embodiments, data source 90 transmits response 16 to adapter80, which may perform translating and/or formatting operations asdiscussed above. Adapter 80 may then transmit response 16 toorchestration component 60.

At step 320, orchestration component 60 determines whether there are anyremaining unprocessed backend calls 14. If yes, operation repeats byreturning to step 306. If not, operation proceeds at step 324.

At step 324, orchestration component 60 combines the received responses16′ into a combined response 16′. In particular embodiments,orchestration component 60 combines multiple received responses 16′ intoa combined response 16′. For example, orchestration component 60 maycombine responses 16′ received in response to serial backend calls 14and parallel backend calls 14 into a combined backend call 14. Onceseparate responses 16′ are combined into a combined response 16′,orchestration component 60 may transmit the combined response 16′ toother component of system 10 for further processing as described above.

The steps illustrated in FIG. 3 may be combined, modified, or deletedwhere appropriate, and additional steps may also be added to thoseshown. Additionally, the steps may be performed in any suitable orderwithout departing from the scope of the present disclosure.

FIG. 4 illustrates an example Graphical User Interface (“GUI”) 400 thatan operator of system 10 may utilize to create, manage, and/or editworkflows 62. As shown in FIG. 4, GUI 400 includes search area 402,search results 404, backend call window 406, backend call editor 408,and workflow editor 410. In particular embodiments, a user may enter oneor more search terms in search area 402 to retrieve particular workflows62. Users may search based on workflow name, a workflow start timeand/or end time, a work flow status, and/or any other relevant searchcriteria. Results from searches may appear in search results 404. Asshown in FIG. 4, workflow 62 is displayed for the example searchperformed in search area 402. Backend call window 406 displaysparticular backend calls 14 included in workflow 62 selected in searchresults 404. A user may select a particular backend call 14 displayed inbackend call window 406, and may edit the selected backend call 14 inbackend call editor 408.

GUI 400 also includes workflow editor 410. Using workflow editor 410, auser may add, create, remove, modify, and/or specify a sequence forbackend calls 14.

Workflow editor may comprise a window in which a user may manipulategraphical representations of backend calls 14. For example, GUI 400 maydisplay a list of predefined backend calls 14, which a user may selectand/or arrange to create a workflow 62. Backend calls 14 may be listedaccording to an operation performed by the respective backend call 14.For example, GUI 400 may list a “write data” backend call 14, “retrievedata” backend call 14, and/or a “delete data” backend call 14. Thus, GUI400 may display graphical representations of predefined operationsperformed by data services module 50. Moreover, a user may also usearrows, lines, and/or other indicators to create or modify a sequence inwhich selected backend calls 14 are performed, and may associate backendcalls 14 together to create parallel backend calls 14. Further, a usermay specify that data included in a response 16 received in response toa particular backend call 14 is used as a parameter to a subsequentbackend call 14.

FIG. 5 illustrates an example visibility policy 500 in accordance with aparticular embodiment of system 10. As shown in FIG. 5, visibilitypolicy 76 includes rules 502 a and 502 b. Rules 502 a and 502 b eachinclude the following fields: environment field 504, subject field 506,resource field 508, action field 510, and effect field 512. Environmentfield 504 indicates a general classification of the calling application.Subject field 506 indicates a role of a user that visibility policy 76applies to, such as, for example, financial advisor and/or customeragent. Resource field 508 indicates the type of resource being accessed,such as, for example, profile and/or asset. Action field 510 indicatesthe types of action the rule 502 applies to, such as, for example,update, delete, add, and retrieve. Effect field 512 indicates the policyapplied by rule 502, such as, for example, allow, deny, and/or blocksilently.

In the example visibility policy 76, rule 502 a indicates that financialadvisors (as indicated in subject field 506) are allowed (as indicatedin effect field 512) to update (as indicated in action field 510) aprofile (as indicated in resource field 508). Rule 502 b indicates thatfinancial advisors (as indicated in subject field 506) are denied (asindicated in effect field 512) from deleting (as indicated in actionfield 510) a profile (as indicated in resource field 508). Although FIG.5 illustrates for purposes of example a particular number and type ofvisibility policy 76, it should be understood that visibility policies76 of any type supporting any number and/or type of rules may becreated.

Although the present disclosure has been described with severalembodiments, numerous changes, variations, alterations, transformations,and modifications may be suggested to one skilled in the art, and it isintended that the present disclosure encompass such changes, variations,alterations, transformations, and modifications as fall within the scopeof the appended claims.

What is claimed is:
 1. A method, comprising: receiving a request fordata from a client; based on the request, determining a workflow toprocess the request, the workflow defining a particular sequence fortransmitting a plurality of backend calls, wherein the particularsequence comprises transmitting a first backend call to a first datasource and then transmitting a second backend call to a second datasource; based on the workflow, generating the plurality of backendcalls; based on the plurality of backend calls, selecting one or moredata sources from a plurality of data sources; transmitting one or moreof the plurality of backend calls to the selected data sources in theparticular sequence; receiving, from the first data source, a firstresponse; determining from the first response one or more additionalbackend calls, wherein the one or more additional backend calls performadditional tasks identified in the first response to the first backendcall; based upon the one or more additional backend calls, selecting oneor more additional data sources from the plurality of data sources;transmitting the one or more additional backend calls to the one or moreadditional data sources; receiving, from the one or more additional datasources, one or more additional responses; and receiving, from thesecond data source, a second response.
 2. The method of claim 1, furthercomprising: combining the first and second responses received from thefirst and second data sources into a combined response; and transmittingthe combined response to the client.
 3. The method of claim 1, whereintransmitting one or more of the plurality of backend calls to theselected data sources comprises transmitting each of the plurality ofbackend calls to the selected data sources in parallel.
 4. The method ofclaim 1, wherein transmitting one or more of the plurality of backendcalls to the selected data sources comprises transmitting the pluralityof backend calls to the selected data sources serially.
 5. The method ofclaim 1, wherein transmitting one or more of the plurality of backendcalls to the selected data sources comprises transmitting selected onesof the plurality of backend calls to the selected data sources inparallel and transmitting selected ones of the plurality of backendcalls to the selected data sources serially.
 6. The method of claim 1,further comprising: receiving the plurality of backend calls at anadapter, wherein each of the backend calls has a first format;translating each of the plurality of backend calls into one of aplurality of second formats, wherein each of the plurality of secondformats are readable by one or more of the selected data sources; andwherein transmitting one or more of the plurality of backend calls tothe selected data sources comprises transmitting the one or moreplurality of backend calls in one of the plurality of second formats tothe selected data sources.
 7. The method of claim 1, wherein receivingthe first and second responses comprises receiving at an adapter, fromthe first and second data sources, a response, wherein each of theresponses has one of a plurality of first formats; and furthercomprising: translating each of the responses in one of the plurality offirst formats into a second format, wherein the second format isreadable by the client; combining the responses in the second formatinto a combined response; and transmitting the combined response to theclient.
 8. A system, comprising: a data services module configured to:receive a request for data from a client; based on the request,determine a workflow to process the request, the workflow defining aparticular sequence for transmitting a plurality of backend calls,wherein the particular sequence comprises transmitting a first backendcall to a first data source and then transmitting a second backend callto a second data source; based on the workflow, generate a plurality ofbackend calls; based on the plurality of backend calls, select one ormore data sources from a plurality of data sources; transmit one or moreof the plurality of backend calls to the selected data sources in theparticular sequence; and receive, from the first data source, a firstresponse; determine from the first response one or more additionalbackend calls, wherein the one or more additional backend calls performadditional tasks identified in the first response to the first backendcall; based upon the one or more additional backend calls, select one ormore additional data sources from the plurality of data sources;transmit the one or more additional backend calls to the one or moreadditional data sources; receive, from the one or more additional datasources, one or more additional responses; and receiving, from thesecond data source, a second response; and the one or more data sourcesconfigured to: receive, from the data services module the one or more ofthe plurality of backend calls; and transmit, to the data servicesmodule, the response.
 9. The system of claim 8, wherein the dataservices module is configured to transmit one or more of the pluralityof backend calls to the selected data sources by transmitting each ofthe plurality of backend calls to the selected data sources in parallel.10. The system of claim 8, wherein the data services module isconfigured to transmit one or more of the plurality of backend calls tothe selected data sources by transmitting the plurality of backend callsto the selected data sources serially.
 11. The system of claim 8,wherein the data services module is configured to transmit one or moreof the plurality of backend calls to the selected data sources bytransmitting selected ones of the plurality of backend calls to theselected data sources in parallel and transmitting selected ones of theplurality of backend calls to the selected data sources serially. 12.The system of claim 8, further comprising: an adapter configured to:receive the plurality of backend calls at an adapter, wherein each ofthe backend calls has a first format; translate each of the plurality ofbackend calls into one of a plurality of second formats, wherein each ofthe plurality of second formats are readable by one or more of theselected data sources; and transmit the one or more plurality of backendcalls to the adapter in one of the plurality of second formats to theselected data sources; and wherein the data services module isconfigured to transmit one or more of the plurality of backend calls tothe selected data sources by transmitting the one or more plurality ofbackend calls to the adapter.
 13. The method of claim 8, furthercomprising: an adapter configured to receive, from the first and seconddata sources the first and second responses, wherein each of theresponses has one of a plurality of first formats; and translate each ofthe responses in one of the plurality of first formats into a secondformat, wherein the second format is readable by the client; and whereinthe data service module is configured to receive, from each of theselected data sources, a response to the plurality of backend calls byreceiving the response in the second format from the adapter; andwherein the data services module is further configured to; combine theresponses in the second format into a combined response; and transmitthe combined response to the client.
 14. A computer readablenon-transitory medium encoded with logic, the logic configured, whenexecuted on a processor, to: receive a request for data from a client;based on the request, determine a workflow to process the request, theworkflow defining a particular sequence for transmitting a plurality ofbackend calls, wherein the particular sequence comprises transmitting afirst backend call to a first data source and then transmitting a secondbackend call to a second data source; based on the workflow, generate aplurality of backend calls; based on the plurality of backend calls,select one or more data sources from a plurality of data sources;transmit one or more of the plurality of backend calls to the selecteddata sources in the particular sequence; and receive, from the firstdata source, a first response; determine from the first response one ormore additional backend calls, wherein the one or more additionalbackend calls perform additional tasks identified in the first responseto the first backend call; based upon the one or more additional backendcalls, select one or more additional data sources from the plurality ofdata sources; transmit the one or more additional backend calls to theone or more additional data sources; receive, from the one or moreadditional data sources, one or more additional responses; and receive,from the second data source, a second response.
 15. The computerreadable non-transitory medium of claim 14, wherein the logic is furtherconfigured to: combine the first and second responses received from thefirst and second data sources into a combined response; and transmit thecombined response to the client.
 16. The computer readablenon-transitory medium of claim 14, wherein the logic is configured totransmit one or more of the plurality of backend calls to the selecteddata sources by transmitting each of the plurality of backend calls tothe selected data sources in parallel.
 17. The computer readablenon-transitory medium of claim 14, wherein the logic is configured totransmit one or more of the plurality of backend calls to the selecteddata sources by transmitting the plurality of backend calls to theselected data sources serially.
 18. The computer readable non-transitorymedium of claim 14, wherein the logic is configured to transmit one ormore of the plurality of backend calls to the selected data sources bytransmitting selected ones of the plurality of backend calls to theselected data sources in parallel and transmitting selected ones of theplurality of backend calls to the selected data sources serially. 19.The computer readable non-transitory medium of claim 14, wherein thelogic is further configured to: receive the plurality of backend calls,wherein each of the backend calls has a first format; translate each ofthe plurality of backend calls into one of a plurality of secondformats, wherein each of the plurality of second formats are readable byone or more of the selected data sources; and wherein the logic isconfigured to transmit one or more of the plurality of backend calls tothe selected data sources by transmitting the one or more plurality ofbackend calls in one of the plurality of second formats to the selecteddata sources.
 20. The computer readable non-transitory medium of claim14, wherein the logic is configured to receive the first and secondresponses by receiving, from the first and second data sources, aresponse, wherein each of the responses has one of a plurality of firstformats; and wherein the logic is further configured to: translate eachof the responses in one of the plurality of first formats into a secondformat, wherein the second format is readable by the client; combine theresponses in the second format into a combined response; and transmitthe combined response to the client.